Previously when generating the FirstTrip or ServiceEnded states, RDS
would construct a "fake" Departure from a Schedule, essentially just
for the convenience of existing serialization functions many steps down
the line that expected a Departure. Refactor this so only the Schedule
is returned and this construction happens on-demand, only when required
to avoid deeper refactoring. This simplifies some code and test setup.

Additionally:

* Rename the "special trip type" `last_trip` to `service_ended` to
  better reflect its meaning and avoid confusion with actual "last
  trip" tags on countdowns, which we will be introducing soon.

* Refactor the "ID" field on the RDS Headways state out of existence,
  synthesizing an ID only in the one place where the client needs one.

Pre-RDS DUPs displayed skipped/cancelled departures for CR and Ferry as
a struck-through time; not including these in the RDS rework would be a
regression. Solely adding the `include_scheduled_cancelled?` option to
RDS departure fetching would cause a client crash due to passing e.g.
skipped subway departures (which should not be displayed) through to
serialization; and further adding a `schedule_route_type_filter` option
to mimic non-RDS departure fetching would result in incorrect states
because e.g. scheduled subway departures *should* be taken into account
internally when determining these.

The result is that non-trivial refactoring is necessary to fix this
issue, as well as some opportunistic refactoring while in the area. The
key points are:

* Simplify and rework `RDS` logic for better adherence to the spec.

  * The `Countdowns` state is now always non-empty, which simplifies
    some logic. In cases where it would have been empty before, either
    a more appropriate state or no state at all is generated. This is a
    step towards refactoring around "items" instead of "states".

  * Remove warning when no state is generated, since this is expected
    to happen normally (both in the spec and in the current code).

  * Fix a bug where scheduled-only departures would still be presented
    if the destination was impacted by an alert (they should not be).

  * Fix a bug where the "effective end of service" calculation did not
    take headways into account.

  * Fix some typespecs and make types private when they don't need to
    be public.

* Departures serialization now decides whether to include the original
  scheduled time of a departure based on whether the relevant data is
  present, instead of only (and always) doing this for CR and ferry.
  Producers of the widget should omit schedules themselves for cases
  where schedule data should never be displayed, i.e. "headway-based
  service". Existing non-RDS departures logic only fetches schedules
  for CR and ferry, so there is no change there.

  * Also prevent accidentally displaying skipped/cancelled departures
    on screen types that don't support them, which could potentially
    present a cancelled time as though it was a normal scheduled time.